Summary

All parser bookkeeping (has_fmt / has_fmtu / has_instance / instance_idx / instance_offset / formats / format_units / msg_id2name / msg_name2id / field_name2idx / messages_map / multipliers / units) lives in DataLoadAPBIN member variables, but the plugin instance is reused for every file load in a session and readDataFromFile never reset any of them. This patch clears them at the top of readDataFromFile.

Problem

ArduPilot assigns msg_ids dynamically per boot, so loading two logs in sequence can put a different message at the same id. The FMTU handler guards the # check with if (!has_instance[msg_id]), so a stale true from a previous file's message is never re-evaluated. When the next log puts a non-instanced message at that id, it gets treated as instanced and a byte from its payload (at the previous file's instance_offset) is read as the instance number.

Reproducer using two real ArduPilot logs from the same vehicle (one had msg_id 251 = SURF, the next had msg_id 251 = HEAT):

Before fix:
  After loading log_A.bin (msg_id 251 == SURF):
    HEAT series count: 5
  After loading log_B.bin (msg_id 251 == HEAT):
    HEAT series count: 308       <-- spurious /HEAT/#-102/...,
                                     /HEAT/#-105/..., etc.

After fix:
  After loading log_A.bin:  HEAT series count: 5
  After loading log_B.bin:  HEAT series count: 5

The accumulated messages_map also causes timestamps that already went through apply_multipliers + apply_timesync to be re-processed on the next load, producing far-future stray data points that compress the plot's useful range against one edge.

Solution

std::fill the bool/int arrays, value-initialize the log_Format / log_Format_Units structs, clear the strings in msg_id2name, and call .clear() on the maps. Verified the fix by loading the same two-log sequence via QPluginLoader and dumping the resulting PlotDataMapRef.